Add Subject-Side Access Challenge Profile (S-ARAP), Draft 00 - #608

Draft 00 of a subject-side complement to ARAP, for Working Group review.

ARAP routes an operator-side approver's grant into a decision as Context. This routes the signed challenge of the party a decision was rendered about into a decision as Context, on the same decision API, with re-evaluation as the authoritative completion mode. escalate-to-arap-approver hands a challenge to ARAP's Access Request Endpoint rather than defining a parallel one.

It follows ARAP's extension contract: Decision Context members at the extension point ARAP names, two member names registered in ARAP's registry, a PDP metadata parameter, a capability URN, and no registry for profile-defined enumerated values.

Four things to flag.

Mandatory Evaluation applies to PDPs advertising the capability. ARAP requires an implementation to ignore an unrecognised member at an extension point, so a non-implementing PDP disregards subject_side_challenge, and this profile does not override that. Discovery is therefore required before submission, and the text says so.

Notice is the weakest part of the document. A MUST on the enforcing entity's out-of-band delivery is not expressible in this API and not checkable by a conformance suite. A registered Obligation Type with a destination the operator does not select is a better fit, which is the gap I raised on the list in July under "notification obligations: is pointing one outward in scope?". Obligation negotiation is advisory and non-execution is handled rather than forbidden, so an Obligation as specified today would carry less force than the present text. The fulfillment tiers in #521 would close that. I would rather move Notice there than keep an unenforceable MUST, and would take direction on doing it now or waiting for tiers.

decision_ref follows ARAP as published, where evaluation_id and binding_token are interchangeable. #532 would change that. #606 asks which dependent work should pin to. This will be revised to match #532 as settled.

On scope, per #520: this profile is large and the same critique applies. If the WG prefers, the core is Standing plus Mandatory Evaluation, with Notice and the audit substrate as companion documents.

Registrations are requests. Several target registries are still being established, including the base spec's own per #597, so those entries reserve names and can be redirected.

Builds through profiles/Makefile; the all target is updated. Karl has had the full text since 22 July.